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1 FINANCIAL TRANSACTION ACCOUNT USAGE PARAMETER 

2 ACCESS AND CONTROL METHODOLOGY 

3 Related Applications 

O 4 This US Patent Application relates to PCT Applications: PCT/US99/3 1203 filed on 30 

o 

Hj 5 December 1999, published on 2 November 2000; PCT/US99/3 1202, filed on 2 November 2000; 

6 and PCT/US99/31315, filed on 30 December 1999; and the US Patent Applications related 

5 " 7 thereto. The disclosures of each of these documents, as well as the US Patent Applications 

fy 8 corresponding to these PCT applications, are entirely incorporated hereinto by reference. 

€j 9 This application is a continuation-in-part for U.S. Application Serial No. 

Ho 09/298,4 17,entitled METHOD FOR PROCESSING A GROUP OF ACCOUNTS 

1 1 CORRESPONDING TO DIFFERENT PRODUCTS , filed April 23, 1999. 

12 Background of the Invention 

13 Financial transaction card products, i.e. credit and debit cards, are very popular for 

14 conducting a wide range of consumer and business transactions involving payments for various 

15 goods and services. They offer significant advantages over other payment methods, such as cash 

16 and checks. These advantages include convenience, security and acceptability to providers of 

17 goods and services. Another advantage is that such transactional cards can be used remotely, i.e, 

18 by telephone or by global computer network ("internet"), as well as at points-of-sale. 
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1 Multiple account/product relationships with a single issuer are common. They can 

2 accommodate the needs of individual account holders who use different products for different 

3 purposes. A typical example involves business and personal accounts with a single issuer. With 

4 this arrangement the account holder can separate business and personal purchases for record 

5 keeping and tax reporting purposes. Card issuers tend to foster relationships with their preferred 

6 customers by encouraging them to open additional accounts. 

O? Many consumers are inundated with solicitations from card issuers. The proliferation of 

! 't 8 their respective products has provided consumers with a wide range of choices and considerable 

y g 

J 9 flexibility in managing their credit/debit finances, both personal and business-related. The card 

3 10 issuers, such as banks and other financial institutions, typically promote the use of their respective 

01 1 products through various incentive programs involving features of their products. These features 

]|2 can include increased spending limits, favorable interest rates and "reward points" for product 

13 usage. The general trend has been for the functionalities of such products to increase in scope and 

14 complexity as issuers offer more choices and flexibility. Such choices and flexibility are 

15 particularly desirable in multiple account/product relationships with single issuers. 

16 Usage parameter flexibility and account holder control thereof are highly desirable in 

17 multiple account/product relationships with single issuers. For example, an account holder may 

18 procure a first product for his or her personal use, another product for the use of his or her 

19 dependents, a third product for business use, etc. The account holder may require different usage 

20 parameters for his or her respective products, which often share unique and dynamic relationships. 

21 As such multiple account/product relationships vary over time, the account holders may find it 
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1 highly desirable to take advantage of the available usage parameter flexibility in order to 

2 accommodate the needs associated with various products and accounts and to manage their 

3 usage. Accordingly, a methodology which permits such usage parameter access and control is 

4 highly desirable. 

5 Many credit/debit card account holders encounter personal and business circumstances 

6 which necessitate changing their financial transaction card product usage parameters. For 
Jf7 example, account holders may procure multiple cards associated with individual credit/debit 
{S8 products. The additional cards are often distributed to family members for personal use and 
59 employees (where the account holder is a business) for business use, etc. Account holders can 
3 10 establish certain usage parameters for the additional cards on their credit/debit products. Over 
fll time, changing business and personal circumstances may alter the preferred usage parameters. 
Jib Accordingly, in multiple account/product relationships there is a need for the account holders to 

13 have access to and control over the product usage parameters. In such relationships, it is also 

14 desirable to provide methodologies for controlling usage parameter access differently among the 

15 different accounts and products, which can emanate from single or multiple issuers. Moreover, 

16 there is a need for such products which permit continuous, interactive access to and control over 

17 such usage parameters by account holders. Such functionalities are desirable in applications 

18 which are related to relationship processing linking and also in connection with applications which 

19 are not. Thus, both single and multiple account applications can benefit from the methodology of 

20 the present invention. 
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1 Control over the increasingly flexible product usage parameters has generally remained in 

2 the hands of the product issuers. Changing usage parameters on existing accounts/products tends 

3 to be relatively labor-intensive and hence costly using current methodologies. Therefore, for cost- 

4 control purposes, the issuers tend to retain control over the usage parameters for their respective 

5 products. Thus, under current financial transaction product models, relatively little usage 

6 parameter flexibility is available to the account holders. Account holders can presently contact 
S 7 the card issuers through various points-of-access in order to affect such changes. Points-of- 
IM 8 access available to consumers include telephone, automated response unit ("ARU"), global 

i 9 computer network ("internet"), written correspondence, etc. However, usage parameter 

s 10 modifications using current methodologies typically involve employees of the card issuer who 

f% 1 receive the account holders' instructions. The instructions must then be implemented. Additional 

S 2 costs may be incurred by the issuers for recording, confirming and implementing such 

13 modifications. Since product usage parameters may require modification any number of times 

14 during the life of a particular account, the costs associated with providing such services can be 

1 5 significant. Therefore, from the standpoint of the card issuers, consumer-directed usage 

1 6 parameter modifications are generally undesirable and therefore limited. The card issuers 

1 7 generally need to make available such optionality to their customers, even though they have a 

1 8 disincentive for encouraging the exercise of same. Card issuers are presently confronted with the 

1 9 competing objectives of providing their customers with at least some degree of control over their 

20 card usage parameters versus minimizing changes in order to control costs. 
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1 From the standpoint of the consumer/account holder, usage parameter management 

2 typically involves finding the appropriate balance between risk and convenience. For example, 

3 credit card fraud is so pervasive that issuers must devote considerable resources to detecting and 

4 preventing fraudulent transactions. Fraud-control procedures include monitoring usage patterns 

5 such that unusual activity can be promptly detected and dealt with. Usage patterns that are 

6 observed for fraud detection include the geographical locations in which purchases are attempted 
2 7 and the types of purchases. These factors can provide early indications of a stolen card or the 

J S 8 unauthorized use of an account number. 

J 9 Credit card fraud can be controlled somewhat by closing and opening accounts. For 

s 10 example, some credit card issuers advise their customers to close their accounts after attending 

™i 1 major international sporting events, such as the Wimbledon Tennis Tournaments, because the 

%2 attendant risk of fraudulent activity is so high. Although effective, closing and reopening credit 

1 3 card accounts tends to be relatively expensive and thus not a particularly desirable solution. 

1 4 Relatively powerful and sophisticated computer systems have been developed for 

1 5 analyzing data and comparing relationships therebetween quickly and cheaply. Such 

16 computerized systems enable the card issuers to handle the aforementioned parameters quickly 

17 and efficiently. A relatively high degree of control over the usage parameters associated with 

1 8 particular products is therefore feasible. The present invention takes advantage of such available 

19 capabilities by providing consumers with access to and control over such operating parameters 

20 associated with their transactional products. Consumers can thereby determine their thresholds of 

2 1 risk versus convenience in setting such parameters. For example, placing fewer usage restrictions 
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1 on products generally makes their usage more convenient. However, the thresholds for detecting 

2 fraudulent activity are correspondingly lower. The present invention enables account holders to 

3 modify such usage parameters relatively quickly and efficiently through a wide range of access 

4 points. For example, a financial transaction product holder might vary the territorial parameters 

5 for his or her cards in advance of upcoming travel. Significant card usage in locations which are 
; 6 away from home for the account holder might therefore be permissible. Upon concluding the 
g 7 travel, the account holder can reset the usage parameters to their previous conditions whereby 
IH 8 remote usage would activate fraud control procedures. 

fi 9 Moreover, the system and method of the present invention enable such control to be 

f 10 effected globally for multiple cards under individual products and for the accounts individually in a 

[J 1 multiple account relationship. An account holder can thereby adjust the operating usage 

R2 parameters to account for the activities of, for example, his or her dependents as they travel and 

13 as their other circumstances and credit needs change. 

14 Account holder access to and control over such usage parameters has become increasingly 

1 5 desirable. Such optionality, particularly with respect to quantitative usage parameters, enables 

16 consumers to balance the risk/convenience factors discussed above. With the system and method 

17 of the present invention, consumers are provided with the ability to access and control such usage 

18 parameters at the card or dependent account level, as contrasted with previous technology which 

19 limited such control to the group or master account level. Such card level usage parameter 

20 management is accomplished by applying technology to a system-generated process for applying 
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1 usage criteria to generate responses from the consumers. A dynamic control of known consumer 

2 needs can thus be provided. 

3 The access and control methodology of the present invention recognizes the desirability of 

4 enabling usage parameter access, control and management by account holders and, optionally, by 

5 cardholders. From the standpoint of the account holders and cardholders, greater access, control 
_ 6 and management facilitates tailoring the usage parameters associated with credit/debit products to 
q7 changing personal and business circumstances, objectives and functionalities. Such user-based 

in 8 control can be very accommodating by providing multiple points of access, some of which are not 

£f 9 limited to usage within normal business hours. Thus, the objective of maximizing account 

* 10 holder/cardholder access on a relatively continuous basis can be achieved. Moreover, such access 

[H 1 can occur in real time whereby usage parameter modifications can be implemented almost 

||2 instantaneously. Consumers are thus empowered to adapt their credit/debit products in rapid 

13 response to their needs and applications for same, as well as the needs and applications for the 

14 additional cardholders associated with particular credit/debit products. The products are thus tied 

15 to and highly responsive to relationship management imposed by the account holders, for 

16 example, among the multiple cardholders associated with their respective accounts. Such usage 

17 parameters can be highly customized by the account holders to accommodate the relationships 

18 with and among their respective cardholders. 

19 As discussed above, an important advantage to the account holders is balancing and 

20 managing the threshold between risk and convenience through customizing the product usage 

21 parameters in real time in response to evolving circumstances. Still further, an advantage to the 
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account holders relates to maintaining privacy with respect to their financial affairs and those of 

2 the cardholders associated with their accounts. By leveraging current technologies to facilitate 

3 the anonymous implementation of such usage parameter modifications, account holder concerns 

4 over privacy can be lessened. In particular, employees of the card processing and service provider 

5 organizations, and the card issuers, need not be involved in such usage parameter modifications. 

6 Various privacy and security features can be implemented to protect the account holders and 
^7 cardholders. 

8 The availability of such usage parameter access, control and management can be achieved 

by leveraging current technology in order to achieve such objectives. Consumers are thus given 

10 greater control over their credit/debit products. Part of the current technology which can be 

H 1 leveraged to facilitate the access, control and management features of the present invention 
%2 involves relational databases. Data can thereby be manipulated and usage parameters can be 
"l 3 modified in real time using various points of access in order to enhance the "realness", speed and 

14 flexibility of the methodology of the present invention. Such performance enhancements can be 

1 5 achieved utilizing current technology without increasing costs significantly. 

16 Another significant area of technological development relates to security enhancements. 

1 7 Hardware and software with increasing sophistication are being developed and commercialized to 

1 8 enhance security utilizing such technologies as biometrics, authentication functions, etc. These 

19 technologies can be implemented with the methodology of the present invention to enhance its 

20 security. 
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1 Circumstances giving rise to product usage modifications by consumers include the 

2 maturing of individual cardholders with corresponding greater financial needs and responsibilities, 

3 and budget changes in both personal and business contexts, for example in response to anticipated 

4 changes in usage. Such optionality provides dynamic control of known consumer needs and 

5 avoids the problems with product usage controls which are either too restrictive or too 

6 permissive. 

2 7 From the standpoint of the card processing and service providers and the card issuers, 

i X 8 shifting dynamic control of product usage to consumers has the effect of enhancing product value. 

2 9 Enhanced product value has a number of benefits, including greater consumer loyalty and more 

3 10 extensive use of the products of a particular provider. Moreover, card processing and service 

Pi 1 providers and card issuers can reduce their fraud exposure and liability to account holders by 

% 2 shifting access, control and management of usage parameters to the account holders, who are 

~1 3 generally in the best position to be aware of and respond to their unique and dynamic 

14 circumstances. 

1 5 Credit/debit products are typically subject to various rules regarding their usage. Such 

16 rules can be established by the card processing and service providers and the card issuers. Other 

17 rules and regulations are established by statute and regulation, including statutes, rules and 

1 8 regulations pertaining to financial institutions, credit and lending practices and credit reporting. 

19 The methodology of the present invention enables account holders to access, control and manage 

20 their usage parameters, all subject to compliance with such laws, rules and regulations. Account 

2 1 holders can be presented with various allowable functionality options under the methodology of 
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the present invention. Once requested, such product usage parameter modifications can again be 
tested against allowable functionalities. 

The financial transaction account prior art methodologies provided some access by the 
account holders to their account usage parameters. For example, various product usage 
parameters could be selected as options when the accounts were first opened. Such usage 
parameters were typically incorporated into product agreements among the account holders, 
issuers and processors. The prior art also provided for the submission of data for updating the 
account records for address changes and the like. Changes to conditions and limitations within 
the financial transactional products were managed by the employees of the issuers or the service 
providers. Speed, flexibility and interactiveness were all relatively limited with such prior art 
methodologies and the technologies formerly available. 

The present invention thus represents a significant shift from the current model of issuer- 
controlled products to a new model characterized by consumer control. The new, consumer- 
controlled model benefits the issuer through less employee involvement and benefits the account 
holder through greater access to and control over the usage of the cards issued on their accounts. 

Heretofore there has not been available a financial transaction account usage parameter 
access and control methodology with the advantages and features of the present invention. 

Summary of the Invention 

The method embodying the present invention meets the needs described above, and other 
needs, by allowing account holders to easily access and modify usage parameters. Any activity 
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1 outside such predefined parameters can be considered fraudulent and immediately declined. Thus, 

2 account transfers can be reduced. Costs incurred for investigating fraud and/or writing off 

3 fraudulent activity can also be reduced. 

4 Issuers can provide account holders with access to their usage parameters via points of 

5 contact utilizing: global computer network ("internet 5 ') web sites; telephone communications; 
, . 6 automated teller machines (ATMs); written correspondence; personal contacts, automated 
q7 response units (ARUs); and e-mail communications. Account holders can establish active and 
m 8 inactive dates for account access. Outside of the active date parameters such accounts are 

;D 9 inaccessible. 

f 10 If an account holder has a suite of related accounts (accounts that are linked together 

rj 1 through relationship processing as described in the incorporated PCT application), he or she can 

q12 specify the amount of credit and the time parameters to be used for an account. Relationship 

13 processing establishes a group level credit line and authorization parameters that define how an 

14 account has access to the group credit line. Using controlled access, some of these choices are 

15 placed in the hands of the account holder. He or she can determine how much of the group credit 

16 line is accessible to an account and the time during which it is accessible. Similarly, cards within 

17 an account can be added or temporarily revoked. Thus, the present invention has wide 

18 applicability to various financial transaction account applications, including but not limited to 

19 those involving grouped accounts. 
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1 Technical Field of the Invention 

2 The present invention relates generally to the field of financial transaction card products, 

3 and in particular to methodologies for accessing and controlling account usage parameters. 

4 Brief Description of the Drawing s 

3 a 5 Fig. 1 is a block diagram illustrating an exemplary relationship between a card processing 

o 

q6 and service provider, issuers and cardholders. 

|||7 Fig. 2 is a block diagram illustrating an exemplary relationship between a card processing 

fl 8 and service provider, an issuer and the cardholders within a group. 

: 9 Fig. 3 is a block diagram illustrating the relationship between a card processing and service 

jJO provider, issuers and the cardholders within a group. 

gl 1 Fig. 4A is a block diagram illustrating the files included in the group master data financial 

12 records. 

13 Fig. 4B is a block diagram illustrating some of the component parts of group master data 

14 financial records. 

15 Fig. 5 is a flow diagram illustrating steps for building a group. 

16 Fig. 6 is a flow diagram illustrating steps for creating a group using existing accounts. 

17 Fig. 7A is a flow diagram illustrating steps for adding a dependent account to a group. 

18 Fig. 7B is a flow diagram illustrating steps for authorizing a request from a group member 

19 account. 

20 Fig. 8A is a flow diagram illustrating steps for applying payments. 
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1 Fig. 8B is a continuation of Fig. 8A. 

2 Fig. 9 is a flow diagram illustrating steps for statementing. 

3 Fig. 10 is a flow diagram illustrating steps for redeeming group reward points. 

4 Fig. 1 1 is a block diagram of some of the major components in a system for practicing the 

5 financial transaction account access methodology of the present invention. 

6 Fig. 12 is a flow diagram illustrating steps for access by an account holder, 

S 7 Fig. 13 is a block diagram of a system showing alternative points of entry for an account 

£» S 

Ifj 8 holder interfacing with the financial transaction account system. 
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1 Detailed Description of the Preferred Embodiments 

2 As required, detailed embodiments of the present invention are disclosed herein; however, 

3 it is to be understood that the disclosed embodiments are merely exemplary of the invention, 

4 which may be embodied in various forms. Therefore, specific structural and functional details 

5 disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a 

6 representative basis for teaching one skilled in the art to variously employ the present invention in 
if 7 virtually any appropriately detailed structure. 

S 8 ' The detailed description which follows is represented largely in terms of processes 



and symbolic representations of operations by a conventional computer. The processes and 

= 10 operations performed by the computer, in both a stand-alone environment and a distributed 

B 1 computing environment, include the manipulation of signals by a processor and the maintenance 

fb of these signals within a data set, such as a database and a data structure. Each of these data sets 

13 and data structures are resident in one or more memory storage devices. Basically, a data set is a 

14 collection of related information in separate elements that are manipulated as a unit. A data 

1 5 structure is a structured organizational scheme that encapsulates data in order to support data 

1 6 interpretation and data operations. The data structure imposes a physical organization upon the 

17 collection of data stored within a memory storage device and represents specific electrical or 

18 magnetic elements. 

19 For purposes of this disclosure, a method or process is generally conceived to be a 

20 sequence of manual or computer-executed steps leading to a desired result. These steps generally 

21 require physical manipulations of physical quantities. In addition, it should be understood that the 
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1 methods and systems described herein are not related or limited to any particular computer (stand- 

2 alone or distributed) or apparatus. Furthermore, the methods and systems are not related or 

3 limited to any particular communication architecture. Thus, one skilled in the art will be able to 

4 implement the systems and methods of the present invention with general purpose machines or 

5 specially customized programable devices according to the teachings of this disclosure. 

6 Card Processing and Service Provider. Issuers, and Cardholders 

2 7 The processing of a credit card transaction typically involves the cardholder, a merchant, a 

. "i 8 merchant acquirer, the card issuer, and a card processing and service provider. Fig. 1 illustrates an 

q 9 exemplary relationship between a card processing and service provider 100, a number of issuers 

■ 10 102a, 102b... 102c, and a number of cardholders 120. The card processing and service provider 

p4i ioo supports the issuers by authorizing and processing monetary transactions, as well as 

2l2 providing support for creating new accounts, modifying accounts, controlling communications to 

^13 cardholders and building reward programs. An issuer, such as issuer 102b, is typically a bank or 

14 other financial institution that issues one or more credit card products. The issuer manages 

1 5 transaction processing at the account level. An issuer typically manages a number of accounts 

16 using a hierarchy, such as the product/systems (BIN/IIN), principal, and agent hierarchy shown in 

17 Fig. 1. The cardholders 120 are typically individuals holding a general purpose credit card or 

18 general purpose charge card, such as a VISA, MASTERCARD, or private label card. In addition 

19 to the elements shown in Fig. 1, additional elements (not shown) may also be included. For 

20 example, additional issuers, products/systems, principals, and agents may exist. 
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1 An issuer can issue different types and versions of credit card products. For example, 

2 issuer 102b could offer a VISA product and a MASTERCARD product. Each product could be 

3 offered in standard, gold and platinum versions. The product/systems blocks shown in Fig. 1 

4 correspond to different products. If issuer 102b issues a VISA product and a MASTERCARD 

5 product, then product/system 104a could correspond to the MASTERCARD product. An issuer 

6 typically uses either a BIN (Bank Identification Number) or an IIN (Issuer Identification Number) 
^7 to identify its different credit card products. 

! X 8 Issuers typically use additional levels of reporting structures below the product/system 

3 9 level to manage large portfolios. Fig. 1 illustrates that below the product/system level is the 

»"l0 principal level and below the principal level is the agent level. The divisions between the principal 

pi 1 level and the agent level are typically defined by the issuer. Some issuers use the principal level 

S\2 and the agent level to make geographical divisions. For example, principal block 106a could 

13 correspond to a geographic region, such as the southeast, and agent block 1 10a could correspond 

14 to a state within that region. The cardholders 120 are located below the agent level. As shown in 

1 5 Fig. 1, a number of cardholders can be associated with a single agent. Fig. 1 illustrates an example 

16 of the hierarchical relationships that exist between an issuer and a cardholder. As will be apparent 

17 to those skilled in the art based on the teaching of this disclosure, alternative hierarchies are also 

18 possible. 

1 9 An individual can hold a number of different cards corresponding to a number of different 

20 accounts. Although the same cardholder is associated with each of the accounts, each account is 

21 processed independently by the issuer. If several cardholders are in the same family, then each 
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cardholder may hold several cards. In the case of a family, the cardholders may be related and the 
payments may be made from family funds, but each account is still processed independently. For 
example, Table 1 illustrates the credit cards held by a typical family. 
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TABLE 1 



J{ 9 Each of the accounts shown in Table 1 is an independent account from the issuer's 

1*10 perspective. The standard MASTERCARD account associated with the daughter (account 6) is 

H 1 independent of the standard MASTERCARD account associated with the grandfather (account 8) 

C 12 and the gold MASTERCARD account associated with the mother (account 2) is independent of 

13 the gold MASTERCARD account associated with the father (account 3). The processing options 

14 used by the issuer to process the accounts shown in Table 1 can differ by product. 

1 5 The relationships between the different accounts shown in Table 1 , the issuer, and the card 

16 processing and service provider are illustrated in Fig. 2. The card processing and service provider 

17 200 supports issuer 202. The issuer 202 issues a variety of credit card products, including a 

1 8 standard VISA product 204a, a standard MASTERCARD product 204b, a gold MASTERCARD 

19 product 204c, and a private label product 204d. account 1 and account 5 are shown under the 

20 standard VISA product 204a, account 6 and account 8 are shown under the standard 

21 MASTERCARD product 204b, account 2 and account 3 are shown under the gold 
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1 MASTERCARD product 204c, and account 4 and account 7 are shown under the private label 

2 product 204d. 

3 Groups and Group Relationships 

4 The accounts shown in Table 1 and Fig. 2 can be linked together to create a group. A 

5 group can include any number of accounts that correspond to a single issuer. By linking accounts 

6 into a group, group processing can be performed on the accounts that are members of the group 
2 7 while maintaining independent processing of each of the accounts. Each group has a primary 

! K 8 owner. Generally the primary owner corresponds to a cardholder for a key account. For example, 

2 9 the standard VISA account held by the mother could be designated as the key account for the 

ill 

= 10 group shown in Table 1 and Fig. 2. The remaining accounts in the group are referred to as 

m 1 dependent accounts. The relationship between the account and the group is independent of the 

%.2 relationship between the remaining dependent accounts and the group. Typically, the issuer 

13 defines the possible relationships between a dependent account and the group. 

14 Fig. 2 shows one possible organization for a group. Other organizations are also possible. 

15 As shown in Fig. 2, the accounts in a group can be associated with different products. There are 

16 no restrictions on the placement of the accounts in a group at the product/system, principal or 

1 7 agent levels. The accounts in a group can be split between different products/ systems, principals 

18 and agents. The key account and a dependent account can be associated with the same agent. 

19 Multiple dependent accounts can also be associated with the same agent. The accounts associated 

20 with an agent are not required to be in the same group (or any group at all). 
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1 Fig. 3 shows an exemplary group where the key account and dependent account 1 are 

2 associated with the same agent 308a. dependent account 2 is associated with a different agent 

3 308b, but is the same type of product 304a as the key account and dependent account 1. 

4 dependent account 3 is associated with a different principal 306b than the key account, Dependent 

5 account 1, and dependent account 2 is associated with a different agent 308d than dependent 

6 account 3, but is associated with the same principal 306b. Dependent account 5 is a different 
5 7 product 304b than any of the other accounts in the group. Although Fig. 3 only shows a single 
8 8 group, additional groups or individual accounts (such as a pre-designated account as will be 

2 9 discussed below) can exist under issuer 302b. Furthermore, additional groups can exist under the 

■ 10 other issuers 302a, 302c. 

^4 1 Linking the accounts into a group is accomplished by linking a financial record that 

%2 corresponds to each account to the group master data for the group. Fig. 4A illustrates the linking 

^13 of the accounts shown in Table 1 into a group. The group master data 400 includes information 

14 about the group, including group control settings, group aggregate data, and group identifier. The 

1 5 group master data 400 is discussed in more detail below in connection with Fig. 4B. The key 

16 financial record 402 corresponds to the key or primary owner. The key financial record 402 can 

17 also correspond to a key account held by the primary owner. In this example, the key financial 

1 8 record 402 corresponds to the standard VISA account held by the mother. The relationship 420 

1 9 between the key financial record 402 and the group master data 400 is a predefined relationship. 

20 Typically, the relationship is defined in part by the card processing and service provider and in 

21 part by the issuer. 
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1 In addition to the key financial record, the group also includes dependent financial records 

2 404, 406, 408, 410, 412, 414 and 416 that correspond to the dependent accounts. Typically, a 

3 dependent account is associated with each dependent financial record. For example, Account 2 is 

4 associated with dependent financial record 404. Each account is also associated with one or more 

5 cardholders, e.g., the mother is the cardholder associated with account 2. 

6 The dependent accounts in the group can cross product lines. In this example, account 2 
O 7 and account 3 are MASTERCARD products, account 4 and account 7 are private label products, 
li 8 account 5 is a VISA product, and account 6 and account 8 are MASTERCARD products. The 
•q 9 relationship 422 between dependent financial record 404 and the group master data 400 is 

L 10 independent of the relationship between the remaining dependent financial records 406 and 408 

W 1 and the group master data 400. 

Jl2 The dependent accounts can also have different types of ownership. For example, the 

**13 primary owner and a dependent cardholder can be jointly responsible for a dependent account, the 

14 primary owner can be responsible for a dependent account where a dependent cardholder is an 

1 5 authorized user, or a dependent cardholder can be solely responsible for a dependent account. In 

16 addition, a dependent cardholder can be jointly liable with the primary owner for the group 

17 liability. If a dependent cardholder is jointly liable with the primary owner for the group, then the 

18 dependent account is a jointly liable dependent account. 

19 Group Master Data 

20 The group master data 400 is further illustrated in Fig. 4B. Fig. 4B illustrates a number of 

21 files 442-448. Each of the files includes records that contain information about the group and the 
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1 accounts that are members of the group. The group data file 444 includes information about the 

2 group, such as a group identifier, a group cycle code, a group credit line, and a group collector 

3 code. The group identifier identifies the group. Each of the records associated with the group 

4 includes the group identifier. It is noted that Fig. 4A shows several dependent accounts. Any one 

5 of these dependent accounts could be the account associated with a pre-designated credit card, 

6 and the discussion that follows will be applicable to such a credit card. 

§7 A group cycle code indicates the cycle code for the group. If the group includes a key 

! n 8 account, then the cycle code for the key account typically is used as the group cycle code. If the 

3 9 group does not include a key account, then the group cycle code can be a default cycle code or 

= 10 can be based upon the cycle code of one of the dependent accounts in the group. The group credit 

pjl line specifies the credit available for the accounts in the group that authorize against the group 

£h credit line. The group collector code may be set once a collector is assigned to one of the 

^13 accounts in the group. A collector may be assigned because the account is delinquent. If another 

14 account in the group becomes delinquent, then the group collector code is checked and the same 

1 5 collector is assigned to that account if a group collection option is used. 

16 The primary owner file 442 includes information about the primary owner of the group. 

17 The primary owner is the individual that is liable for the group. If more than one individual is 

18 liable for the group, then those individuals are jointly liable for the group and information about 

19 the individuals is stored in the Primary Owner file 442. For example, a primary owner and a 

20 dependent cardholder could be jointly liable for the group. For simplicity, the term "primary 

21 owner" is used herein to include a single primary owner or joint primary owners. Every group has 



1145278.1 



22 



1 a primary owner. If the group includes a key account, then the key cardholder is the primary 

2 owner. 

3 The group member file 448 includes a record for each of the accounts that is (or was) a 

4 member of the group. Each record includes an account number, an indication as to whether the 

5 account is a key account or a dependent account, and group membership information. A record is 

6 maintained for an account in the group member file 448 even if the account is delinked from the 
5 7 group. Each record includes group membership information which indicates when the account 

in 8 was linked to the group and if the account is no longer a member of the group, when the account 

3 9 was delinked from the group. The address file 446 includes a record for each of the accounts that 

iu 

= 10 is (or was) a member of the group. Each record includes the mailing address of the cardholder 

fMl 1 associated with the account. 

-12 The member relationship file 450 includes a record for each of the accounts that is (or 

*"l3 was) a member of the group. A member relationship record contains information about the 

14 strategy associated with an account. If the strategy associated with the account has changed, then 

1 5 the member relationship record contains information about the previous strategy or strategies, as 

16 well as the current strategy. The member relationship record also contains information about the 

1 7 effective dates of each strategy. 

18 The strategy definition file 452 includes a record for each of the defined strategies. The 

1 9 strategy definition records include the parameters and the parameter values that define the 

20 strategies referred to in the member relationship records, including any parameters and limits that 

21 might be associated with a pre-designated credit card. If the definition of a strategy has changed, 
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1 then the strategy definition record for that strategy also includes the parameter and the parameter 

2 values that defined the previous version or versions of the strategy as well as the effective dates of 

3 each strategy definition. This will be used and particularly of interest in the pre-defined cards that 

4 are the subject of this disclosure. 

5 The member statement file 45 1 includes records for each account that is (or was) a 

6 member of the group. Each record includes a number of fields that store statement data (monetary 
9 7 information) for the associated account. In addition, each record includes a flag that indicates 

S 8 whether the associated account cycles with the group (i.e., has the same cycle code as the group) 
S 9 or cycles independently. The information stored in the member statement file 45 1 is used to 
TlO generate the group statement, dependent statement, and/or a courtesy statement. Dependent and 
n4 1 courtesy statements are particularly helpful for a pre-designated card. 
;fjl2 The group statement file 458 includes records that contain group monetary and group 
1 ~13 non-monetary information. The group monetary information includes the group balances, as well 
14 as the group credit line and group available credit for a particular statement. The group non- 
15 monetary information includes the group payment due date, as well as any parameters associated 

16 with pre-designated cards that are non-monetary in nature. Typically, the group payment due date 

17 is the earliest due date of all the accounts in the group that are paid by the primary owner. The 

18 information stored in the group statement file 458 is used to generate the group statement. 

19 The information in the member statement file 45 1 and the group statement file 458 is used 

20 to determine the initial break up of a group payment. The information is also used to support the 

21 on-line display of statement information to an operator. 
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1 The group rewards file 454 includes a record for each of the reward programs for the 

2 group. Each record includes information about the reward program, such as reward program 

3 identifier and the amount of group points accumulated in that reward program. 

4 The custom calculation definition file 456 and the custom calculation values file 460 

5 support customized group calculations that appear in a field on the group statement. Each custom 

6 calculation definition record includes a formula for a customized group calculation. Typically, a 
Jf 7 formula specifies that a customized group calculation is calculated using monetary elements from 

in 

i S 8 the accounts, including a pre-designated card account, in the group. The value that is calculated 

yr| 9 using the formula is stored in a custom calculation values record. 

s 10 The group payment file 462 includes a record for each group payment received. Each 

I Ml 1 record includes the amount of the group payment and the date the group payments was received. 

ji2 The payment allocations file 466 includes a record for each group payment received. Each record 

13 indicates how the group payment was allocated among the accounts in the group. The group 

14 reversal file 464 includes a record for each group payment that has been reversed. If a group 

15 payment is reversed, then the reversal is made by referencing the payment allocation file 466 to 

1 6 determine how the payment was originally allocated. 

17 The rejects file 468 includes records of rejections detected during the processing other 

18 than group processing. A record in the rejects file 468 includes a rejection report that provides 

1 9 details of the rejection. 
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1 As will be apparent to those skilled in the art, the files shown in Fig. 4B are exemplary 

2 group master data files. The group master data could be stored using alternative types of files and 

3 records. 

4 Dependent Strategies 

5 Typically, the relationship shown in Fig. 4A between the dependent financial records 422, 

6 424, 426, 428, 430, 432, 434 and the group master data 400 is defined by a set of parameters. 
S 7 The parameters are typically provided by the card processing and service provider. A set of 

! S 8 parameters and parameter values can be selected to create a customized dependent strategy. As 

3 9 will occur to those skilled in the art based on the teaching of this disclosure, a dependent strategy 

* 10 can include the parameters and/or limits associated with a pre-designated credit card, and the 

ft 1 disclosure of the dependent strategies herein can be applied to such a pre-designated credit card. 

%2 Either the card processing and service provider or the issuer can select the parameters and the 

^13 parameter values to create a dependent strategy. Preferably, the card processing and service 

14 provider provides parameters and the issuer selects a set of parameter values that is suitable for a 

1 5 particular situation. Alternatively, the card processing and service provider could provide 

16 strategies rather than parameters to define the strategies. If the card processing and service 

17 provider provides strategies, then each of the issuers supported by the card processing and service 

18 provider chooses among the same group of strategies. However, if the card processing and 

19 service provider provides parameters, then each issuer can customize the strategies offered to its 

20 customers, as will be the case with a pre-designated credit card. In some embodiments the 

21 dependent strategies are labeled. For example, a dependent strategy for a college-age child 



1145278.1 



26 



1 residing at school may have one label, whereas a dependent strategy for a second account for the 

2 primary owner may have another label. This applies to a pre-designated card as well. 

3 A dependent strategy specifies the relationship between a dependent account and the 

4 group by specifying group processing options for the account. The group processing options 

5 provide flexibility in the relationships between the dependent accounts and the group and provide 

6 for automatic processing at the group level. Typically, the dependent strategy includes parameters 
O 7 that define how transactions are authorized for the dependent account, as well as whether 

M 

S 8 payment for the account is due from the primary owner or from the dependent account 

S 9 cardholder. In addition the dependent strategy includes options for payment application, statement 

* 10 generation, cardholder communications, and reward pooling. 

T\k i The parameter values could be selected to create a dependent strategy appropriate for a 

£l2 dependent, college-age child that resides at school. Such parameters are particularly useful if the 

H 13 credit card is pre-designated to apply to certain purchases made at that school, such as books, 

14 restaurants in the immediate vicinity of the campus, any campus store, time limits associated with 

1 5 the school term, or the like. The parameter values could be selected so that the child is liable for 

16 the account and the parent receives information about the activity of the account. Alternatively, 

17 the parameter values could be selected so that the parent and the child are jointly liable for the 

1 8 account and that both the parent and the child receive information about the activity of the 

19 account at their respective residences. Another strategy could be created for a high school-age 

20 child living at home. The parameter values could be selected so that the primary owner, typically 

2 1 the parent, is financially liable for the account and the account has a predetermined limit. The 
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1 primary owner could set the limit on the account. A pre-designated card could also limit the types 

2 and locations of purchases made on the card. 

3 The parameter values could also be selected to create a strategy for a dependent account 

4 held by the primary owner, such as a pre-designated card. The primary owner could use the key 

5 account and a dependent account to segregate expenses as discussed above. The parameter values 

6 could be selected so that the primary owner is liable for the account and detailed information 

S3 7 about the account is included on the group statement. As will be apparent to those skilled in the 

H 8 art, adaptational strategies can also be created to address the needs of other situations, 
y 9 Thus, the invention includes a method for creating a dependent strategy to customize a 

I'lO relationship between a dependent account and a group that comprises steps of: selecting a set of 

hi 1 parameters from a group consisting of time limits, geographic limits, monetary limits, types of 

Cl2 purchases made and use; defining values for the set of parameters to define group processing 

^13 options; labeling the set of parameters and the values for the set of parameters as the dependent 

14 strategy; and associating the dependent strategy with the dependent account to customize the 

1 5 relationship between the decedent account and the group. The various parameters can be modified 

16 as necessary. 

17 Building a Group 

18 The steps associated with building a group are shown in Fig. 5. A new account is opened 

19 at 500 and is designated as the key account (relationship parameter = key) at 502. At decision 

20 box 504 a determination is made if the business rules are validated. A negative decision leads to 

21 an error determination at 520, which can activate appropriate error messaging, resetting the 
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1 procedure, etc. An affirmative decision at 504 leads to initiating group build at 508 and thereafter 

2 to a decision at 5 10 to determine if a dependent document is to be added. A negative response 

3 leads to an end group build block at 506. An affirmative response leads to the step of opening a 

4 new account wherein the dependent relationship parameters apply. Next a dependent strategy is 

5 selected at 5 14 whereafter a determination of whether or not the business rules have been 

6 validated is made at 5 16, with a negative response leading to the error block at 520 and an 

O 7 affirmative response leading to the dependent strategy being selected at 5 18. The procedure then 

ft 8 loops back to the decision box at 5 10 to determine if another dependent document is to be added, 

9 and continues to loop until all dependent documents have been added whereafter the end group 

10 build block 506 is reached. 

Ill Creating Group Using Existing Accounts 

| 2 Fig. 6 shows a procedure for creating a group using existing accounts. An account is 

^13 selected as a key account at 600 and a business rule validation decision is made at 602, with a 

14 negative response leading to an error routine at 616 and an affirmative response leading to 

1 5 initiating group build at 604. At decision box 606 a determination is made if a dependent 

16 document is to be added, with a negative response leading to a determination if business rules 

17 have been validated at 612, with a negative response from that leading to the error routine 616. If 

1 8 dependent documents are to be added from 606 (affirmative branch), an account is selected as a 

19 dependent account at 608 and a dependent strategy is selected at 610, whereafter the procedure 

20 loops back to the decision box 606. If the business rules are validated at 612, the procedure 

21 proceeds to update the group master data at 614. 
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1 Adding a Dependent Acc ount to a Group 

2 As discussed above, the pre-designated card can be viewed as being a dependent account. 

3 Therefore, the process for adding a dependent account will now be described. 

4 Once a group is created, additional dependent accounts can be added to the group. The 

5 additional dependent accounts can be newly generated accounts or can be existing accounts. Fig. 

6 7A illustrates the steps for adding a dependent account to an existing group. In step 700, a group 
9 7 is identified. Typically a group is identified using the group identifier. In step 702, the procedure 

FH 8 determines if a new account is to be added. If a new account is to be added, then the "Yes" 

yi 

'%. 9 branch is followed to step 704. In step 704, a new account is opened and the relationship 

7l0 parameter for the account is set to dependent. A dependent strategy for the new account is 

m 1 selected in step 706. This dependent strategy can include the limits and parameters associated 

%2 with the pre-designated card, such as time limits, geographic limits, use limits and the like as 

**13 discussed above. In step 708, a determination is made as to whether the dependent account 

14 opened in step 704 satisfies the business rules or product usage criteria. If the dependent account 

1 5 satisfies the business rules or product usage criteria, then they are validated and the "Yes" branch 

16 is foUowed to step 710. In step 710, the group master data is updated. If the business rules or 

17 product usage criteria are not validated in step 708, then the "No" branch is followed to step 722 

1 8 and an error occurs. 

19 If the determination in step 702 is that an existing account is to be added, then the "No" 

20 branch is followed to step 712. In step 712, an existing account is selected and the relationship 

21 parameter for the account is set to dependent. A dependent strategy for the account is selected in 
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1 step 714. The parameters for the dependent account created in step 712 are compared to the 

2 business rules or product usage criteria in step 718. If the parameters for the dependent account 

3 satisfy the business rules or product usage criteria, then the usage criteria are validated and the 

4 "Yes" branch is followed to step 720. In step 720, the group master data is updated. However, if 

5 the usage criteria are not validated then the "No" branch is followed to step 722 and an error 

6 occurs. 

7 Although Fig. 7A indicates that the group master data is updated after each dependent 

ry 

j p 8 account is added to the group, the group master data can be updated at other points in the 

yg 9 process. For example, if multiple accounts are to be added to an existing group, then the steps 

s 10 shown in Fig. 7A would be repeated for each account. Rather than updating the group master 

f4 1 data after the addition of each dependent account, the group master data could be updated after 

^L2 the addition of all the dependent accounts. Updating the group master data after the addition of 

13 each account can be used to support on-line processing, whereas updating the group master data 

14 after the addition of a number of dependent accounts can be used to support batch processing. 
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1 Group Processing 

2 Once a group is created, it can be used to perform group processing. Group processing 

3 typically includes authorizing transactions, applying group payments, creating group statements, 

4 controlling cardholder communications, and administering reward programs for the accounts in 

5 the group. Information from both the key account and the dependent accounts are used for group 

6 processing. Each dependent account has an associated dependent strategy that specifies group 
O 7 processing options for the dependent account. Although the accounts of a group are subject to 
!! 8 group processing for some functions, the accounts are treated as individual accounts for other 

9 functions. 

3 10 Authorizing a Transaction 

fH i The dependent strategy for a dependent account, such as a pre-designated credit card, 

B2 specifies the authorization option for the dependent account. The authorization option specifies 

^13 the information that is used to authorize a transaction. In one form of the invention, several 

14 authorization options are available for a dependent account. One authorization option considers 

1 5 only the credit line and available credit of the group, a second option considers only the credit line 

16 and available credit of the dependent account, a third option considers the credit line and the 

17 available credit of both the group and the dependent account. Yet other options are available for 

1 8 time, location, use and the like. The methods for such options are similar to the method for 

19 available credit and thus will not be described, with reference being made to the following 

20 discussion for teaching associated with such options. 
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1 Depending upon the authorization option selected, the authorization processing uses the 

2 group credit line and the group available credit and/or the dependent credit line and the dependent 

3 available credit. The group credit line is a group parameter that typically is set when the group is 

4 created. The dependent credit line is a dependent account parameter that is set when the 

5 dependent account is opened. The group credit line and the dependent credit line can be modified. 

6 The group available credit is calculated real time using activity from the key account (if any) and 
~ 7 any dependent accounts that share the group credit line. A dependent account shares the group 
Jp 8 credit line if payment for the dependent account is due from the primary owner. Generally, the 

5 9 group available credit is calculated by subtracting the current balances and any outstanding 

FU 

a 10 authorizations of the key account and the dependent accounts that share the group credit line 

p~l 1 from the group credit line. Similarly, the dependent available credit is calculated by subtracting the 

JH2 current balance and any outstanding authorizations of the dependent account from the dependent 

13 credit Une. 

14 Fig. 7B illustrates exemplary steps for authorizing a transaction. The steps illustrated in 

15 Fig. 7B can be applied to any of the limits placed on a pre-designated card and are not intended to 

16 be limited to the credit authorization specifically shown. In step 740, an authorization request is 

17 received. The authorization request includes a transaction amount and an account identifier, such 

18 as an account number. In step 742, a determination is made as to whether the account identifier 

19 corresponds to an account that is a member of a group. If the requesting account is not a member 

20 of a group, then the "No" branch is followed to step 752. In step 752, normal authorization 

21 processing occurs using the credit line and the available credit for the account. 
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1 Normal authorization processing typically includes several calculations that use the credit 

2 line and the available credit. For example, authorization may include comparing the amount of the 

3 transaction to the available credit, comparing the amount of the transaction to a percentage 

4 expansion of the credit line, as well as comparing the transaction to past transactions for the 

5 account. Comparing the transaction to past transactions for the account may be used to detect 

6 possible fraudulent uses of a card and may result in the issuance of a referral code. As will be 
O 7 apparent to those skilled in the art, additional calculations can also be performed, especially in 
: *j 8 relation to a pre-designated card. 

S 9 If the determination in step 742 is that the requesting account is a member of a group, then 

llo the "Yes" branch is followed to step 744. In step 744, a determination is made as to whether the 

hi 1 requesting account is a key account or a dependent account. If the requesting account is a key 

g2 account, then the "Yes" branch is followed to step 748. In step 748, normal authorization 

H 13 processing occurs using the group credit line and the group available credit. 

14 If the determination in step 744 is that the requesting account is a dependent account, then 

1 5 the "No" branch is followed to step 746. In step 746, the dependent strategy is checked to 

16 determine the authorization option that corresponds to the dependent account. Fig. 7B illustrates 

17 three possible authorization options, A, B and C. Option A specifies that the credit line and the 

1 8 available credit for the group are used for authorization processing. Option B specifies that the 

1 9 credit line and the available credit for both the group and the dependent account are used for 

20 authorization processing. Option C specifies that the credit line and the available credit for the 

2 1 dependent account are used for authorization processing. 
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1 If the dependent strategy specifies option A, then the method proceeds from step 746 to 

2 step 748 and the credit line and the available credit for the group are used for normal 

3 authorization processing. If the dependent strategy specifies option C, then the method proceeds 

4 from step 746 to step 752 and the credit line and the available credit for the dependent account 

5 are used for normal authorization processing. The difference between the authorization processing 

6 performed in step 748 and the authorization processing performed in step 752 is that step 748 

7 uses group information; whereas, step 752 uses dependent account information. 

I £ 8 If the dependent strategy specifies option B, then the method proceeds from step 746 to 

5 9 step 750 and the credit line and the available credit for both the group and the dependent account 

;s 10 are used for authorization processing. In step 750, the credit line and the available credit for the 

nil l dependent account are used in normal authorization processing. The authorization processing 

]~L2 performed in step 750 is similar to that performed in step 752. However, additional processing is 

13 required for option B. In step 754, a determination is made as to whether the processing 

14 performed in step 750 indicates that the authorization request is authorized. If the processing 

15 performed using the dependent account information indicates that the request is authorized, then 

16 the "Yes" branch is followed to step 758. In step 758, a determination is made as to whether the 

17 transaction amount specified in the authorization request exceeds the group available credit. If the 

18 amount does not exceed the group available credit, then the "Yes" branch is followed to step 760 

19 and the authorization request is approved. If the processing performed in step 754 indicates that 

20 the authorization request is denied or if the comparison performed in step 758 indicates that the 
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1 amount of the request exceeds the group avaUable credit, then the "No" branch is followed to step 

2 756 and the authorization request is declined. 

3 Similar "Yes" and ' *No" branches are set up to correspond to the other limits and product 

4 usage parameters associated with a pre-designated card. Thus, for example, a "Yes" and "No" 

5 branch can be associated with a time limit. Once the above process is completed, and the 

6 transaction would otherwise be approved, the process can move on to the time limit loop. If the 
5 7 time limit has not been exceeded, a "Yes" branch would direct the process back to step 760 and 
W 8 the authorization request would be approved. On the other hand, if the time limit has been 

ill 5 

5 9 exceeded and the pre-designated card cannot be used during this time, the process would move 

llo back to the "No" bop and be directed back to step 756 and the authorization request declined, 

ft 1 Similar loops can be used for any parameter and/or limit placed on the pre-designated card so that 

Cl2 once the credit is authorized, the other limits and/or parameters are checked and the transaction 

^3 either approved or declined accordingly. The above-discussed billing and reporting procedures 

14 will then be used as discussed above. 

1 5 Payments can be made directly to the pre-designated credit card account or via the group 

16 payment method described above and in the incorporated documents. Furthermore, statements 

17 and communications can be generated either directly for the pre-designated card or for a group as 

1 8 described above and in the incorporated documents. 

19 Reward points can be credited directly to the pre-designated card account, or to a group 

20 as discussed above and in the incorporated documents. A pre-designated credit card can be added 

21 to a group according to the methods discussed above and in the incorporated documents. 
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1 Payment Application 

2 Figs. 8A - 8B show a procedure for applying payment. A group payment is received at 

3 800 and a determination made at 802 if it is less than the group balance. If negative, payment is 

4 applied to satisfy the last statement balance for each dependent account at 804 and the remainder 

5 is applied to the key account at 806. If affirmative from 802, a determination is made if the 

6 payment is less than the group minimum payment due ("MPD") at 808. An affirmative 

0 7 determination leads to determining the payment option at 8 10, whereafter a delinquency 

1 ~ 8 consideration decision block is reached at 812. A negative response at 8 12 leads to a calculation 
'% 9 of the MPD ratio for key independent accounts at 814, and applying payment to key and 

s 10 dependent accounts based on MPD ratios at 816. 

fyll An affirmative decision from block 812 leads to an application of the delinquent amount to 

JM12 each account at 820. A determination is made at 822 if there is a remaining amount. If 

^13 affirmative, the procedure leads to 814. If negative, the procedure ends. 

14 A negative response at the decision block 808 leads to Fig. 8B whereat the MPD is 

15 applied to key independent accounts at 824 and a determination is made at 826 if there is a 

16 remaining balance. If negative, the procedure ends. If affirmative, the procedure proceeds to 

17 calculating the remaining balance ratio at 828 and applying the remaining payment using 

18 remaining balance ratio at 830. 

19 Statementing 

20 Fig. 9 shows the procedure for statementing whereat data is calculated for key 

21 independent accounts at 900 and statement data is provided for a key account for a group 
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1 statement at 902. The dependent strategy is checked at 904, which leads to a determination of 

2 whether or not payment for a dependent account is due from the group at 906. If affirmative, the 

3 primary owner and intended recipient of statement data are identified and the statement data is 

4 provided for the dependent account for the group statement at 908. A determination is made at 

5 910 if the dependent card holder receives a courtesy statement. If affirmative, the primary owner 

6 and the intended recipient of the statement data are identified and the statement data is provided 
Q 7 for the dependent account for the group statement at 912. If negative, the procedure ends at 914. 
ly 8 If the result of decision block 906 is negative, the dependent card holder is identified as the 

5 9 intended recipient of the statement data for the dependent account and the statement data for the 

f /io dependent account for the dependent statement is provided at 916. A determination is made at 

fill 918 if dependent account details are included on the group statement. If affirmative, the primary 

mi owner is identified as the intended recipient of statement data for the dependent account and the 

^13 statement data is provided for the group statement at 920. If negative, the primary owner is 

14 identified as the intended recipient of the statement data and the statement data is provided for the 

1 5 dependent account for the group statement at 922. 

16 Redemption 

17 Fig. 10 shows a procedure for redeeming group reward points which commences with a 

1 8 request being received at 1000. At decision block 1002, a determination is made if the requesting 

19 account is a member of a group. If negative, the procedure proceeds to redemption permitted 

20 from requested account only at 1 0 1 6. If affirmative, a determination is made at the next decision 

21 block 1004 if the reward program pools. If negative, the procedure proceeds to 1016. If 
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1 affirmative, the procedure proceeds to 1006 whereat a determination is made if the requesting 

2 account is a key account. If negative, the dependent strategy is checked at 1008 and a 

3 determination made at 1010 if the dependent strategy allows redemption, whereafter a negative 

4 response leads to 1016. An affirmative response from either 1006 or 1010 leads to a 

5 determination if there are sufficient group points to satisfy the redemption request at 1012. If 

6 affirmative, the redemption is authorized at 1018. If negative, the redemption is not authorized at 
g 7 ion. 

. E 8 Product Usage Parameter Access and Control 

iff I 

yp 9 Fig. 1 1 is a block diagram of major components of a system for practicing the usage 

a 10 parameter access and control methodology of the present invention. A financial transaction 

\A 1 product issuer 1 100 exercises control at 1 102 over primary usage parameters 1 104, which can 

J32 include, but are not limited to, some or all of the product usage parameters discussed above. The 

13 primary usage parameters 1 104 are associated with a financial transaction account 1 106. 

14 Transactions 1 108 involving the account 1 106 are implemented with one or more presentation 

15 instruments 1 1 10, which result in transaction records 1 1 12 which are applied to the account as 

16 data at 1 1 14. The account 1 106 and presentation instrument 1110 associated therewith generally 

17 comprise a product offered by the issuer 1 100. 

18 A key account holder 1118 exercises control at 1 120 over the primary usage parameters 

19 1 104, for example when he or she first establishes the account at 1 106. Establishing a new 

20 account at 1 106 provides a key account holder with an initial opportunity to establish the primary 
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usage parameters 1 104, subject to ongoing, interactive, real-time access thereby throughout the 
life of the account according the methodology of the present invention. 

A dependent account holder 1 122 exercises control at 1 124 over dependent usage 
parameters 1 126. The dependent usage parameters 1 126 can overlap the primary usage 
parameters 1 104 to any desired extent. Thus, the methodology of the present invention can 
accommodate dependent account holders 1 122 being given any desired degree of control over the 
usage parameters associated with a particular account, with such degree of control being subject 
to continuos change and updating to accommodate the needs of the account holders 1 1 18 and 
1 122. For example, over a period of time a dependent account holder 1 122 could be given a 
greater degree of control and access over the usage parameters by the key account holder 1118. 
The key account holder 1118, may be, but is not required to be, the primary owner of the account 
1106. 

Fig. 12 shows a flow diagram of an account holder access interface methodology of the 
present invention. From a start box 1202, an account holder enters the system at 1204. Points of 
entry are described in greater detail below and with reference to Fig. 13. 

At decision box 1206 a determination is made if a consumer has a valid identification, such 
as a personal identification number ("PENT), password, etc. A negative determination at 1208 
moves the methodology to an end block 1210 and can produce an error or similar output from the 
system. An affirmative decision at 1212 from decision box 1206 causes the system to determine 
allowed actions at 1214 and provide (output) options relating thereto to the account holder at 
1216. The account holder requests changes to the product usage parameters at 1218. 
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1 At decision box 1220 a determination is made if the requested parameter changes are 

2 within those allowed. A negative response at 1222 transfers the methodology to an end block 

3 1210 and possibly the output of an error message or the like. An affirmative response at 1224 

4 advances the methodology to a confirmation of request entry at 1226, thereafter resulting in a 

5 process change at 1228 with a resulting impact on the account usage parameters 1230 or access 

6 thereto. One of the possible usage parameters within the methodology of the present invention 
!f 7 can consist of the access to the usage parameters, including the ability to modify same within 

i S 8 certain predetermined limits. 

*§3 9 Fig. 13 is a block diagram of various alternative interface functionalities according to the 

i?=jj a 

a 10 methodology of the present invention. Column 1302 depicts an entry mode whereby an account 

f 4 1 holder 1304 can access product usage parameters associated with his or her account. Alternative 

%2 entry modes depicted therein include a website 1304 accessible through the global 

13 communications network ("Internet"), which can consist of the website of an issuer 1306, a third 

14 party 1308 or a processor 13 10. Other alternative entry mode points include telephone 13 12, 

1 5 written correspondence 1314 and e-mail 1316. Other points of entry are generally shown at 1 3 1 8 

16 and can include any suitable means for entry by the account holder 1304 to his or her account. 

17 The path of communication between the account holder 1304 and his or her account is 

18 shown at 1322 and includes a point of entry 1320 (accessed by one or more of the entry modes 

19 discussed above) to the issuer 1306, the third party 1308 or the processor 13 10. The issuer 1306, 

20 the third party 1308 and the processor 13 10 can all be combined into a single functional unit. 

21 Within the financial transaction processing business community, various functions can be allocated 
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1 to different product and service providers, including those depicted in the path 1322. For 

2 example, the third party 1308 can provide a wide range of products and/or services in connection 

3 with the financial transaction products issued by the issuer 1306. Financial transaction processing 

4 is another significant segment of the industry, which utilizes processors, such as the processor 

5 13 10 for performing the data processing and related functions associated with financial 

6 transactions by account holders. 

y 7 The impact to an account for access to the account is shown at 1324 and includes such 

5 S 8 functionalities as communications 1326, an account's credit line 1328, a new user (dependent 

5 9 account, see Fig. 7A), a block user 1332, payment allocations 1334 and transaction authorization 

s 10 parameters 1336. Various other functionalities and usage parameters associated with an account 

Pi 1 or access thereto are collectively depicted at 1338, which is understood to be as broad as might be 

;ifL2 encountered in connection with financial transaction accounts and the various functionalities 

13 associated therewith. 

14 Conclusion 

15 It is to be understood that while certain forms of the present invention have been 

16 illustrated and described herein, it is not to be limited to the specific forms or arrangement of parts 
described and shown. 
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